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IN THE U 



STATES PATENT AND TRADEMARK OFFICE 



Serial No.: 09/723,285 
Filed: November 28, 2000 
Group Art Unit: 2155 
Examiner: Bates, Kevin T. 
Attorney Docket No.: 20-566 

In re Patent Application of: 
BONEFAS 

Title: A SYSTEM AND METHOD FOR SERVERS TO SEND ALERTS TO 
CONNECTIONLESS DEVICES 

June 20, 2007 

(Second-Revised) APPEAL BRIEF 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

In response to the Notification of Non-Compliant Appeal Brief dated 
June 15, 2007 for the above identified application, the Applicant submits the 
following Second-Revised Appeal Brief in accordance with the requirements of 
37C.F.R. § 41.37(c). 

(1) REAL PARTY IN INTEREST 

The real party in interest is Telecommunication Systems, Inc. 

(2) RELATED APPEALS AND INTERFERENCES 

The Applicants and their legal representatives and assignee are not 
aware of any other appeals or interferences that will directly affect or be directly 
affected by or have a bearing on the Board's decision in the appending appeal. 
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(3) STATUS OF THE CLAIMS 

Claims 1-55 are pending in this application. Claims 1-55 stand 

rejected. 

(4) STATUS OF AMENDMENTS 

All amendments have been entered by the Examiner. The 
Applicants have not attempted to file any amendments to the claims after the 
Final Office Action dated March 17, 2006. A Request for Reconsideration filed 
by Applicants on May 16, 2006 was indicated by the Examiner as being entered. 

(5) SUMMARY OF THE CLAIMED SUBJECT MATTER 

Message routers conventionally simply route data from a source to 
a destination with no internal storage of information associated with data packets 
being routed. Conventionally, there is no convenient way of determining what 
devices are attached to a particular protocol gateway since message routers 
conventionally lack internal storage for information associated with routed data 
packets. 

Applicants' invention simplifies sending alerts to a plurality of 
stations attached to a particular protocol gateway by retrieving a station ID from 
customer information previously stored within a message router. The station ID 
is used to determine a communication type and the communication type is used 
to determine an associated protocol gateway. Thus, from a single data packet 
containing customer information, an alert can be sent to other station IDs 
attached to a particular protocol gateway. 

Applicants disclose a method, as recited by claim 1, of sending an 
alert to selected client devices 112 in a communications system 100 including a 
server 122 adapted to run a server application, a message router 124 
communicating with the server 122, a plurality of protocol gateways 116 
communicating with the message routers 124, and a network 114 adapted to 
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couple the server 122 and the protocol gateways 116 to client devices 112 (Page 
11 line 6 to Page 13 line 20 and Figures 1A-1F). The method comprises 
generating an alert with the server application, the alert including customer 
information and is sent to the message router 124 (Page 62, line 7 to Page 64 
line 7; Figures 8A-8C). The station ID of the client device 112 is retrieved from 
the customer information previously stored within the message router 124 (Page 
63, lines 6-8). Determining the communication type of the client device 112 
based on the station ID (Page 63, line 12) and then selecting one or more of the 
plurality of protocol gateways 116 based on the communication type (Page 63, 
lines 12-14. Forwarding the alert to the selected one or more of the plurality of 
protocol gateways 116 (Page 63, lines 12-14) and formatting the alert with the 
protocol gateway 1 16 for the selected client device 112 (Page 12, line 1 1 to Page 
13, line 6). Lastly, the formatted alert is forwarded via the network 114 to the 
selected client device 112 (Page 63, lines 6-23). 

Applicants disclose a method, as recited by claim 23, of sending 
alerts to client devices 112 comprising generation of an alert at a server, the alert 
including a customer ID and a device ID (Page 64, lines 15-24). The alert is 
forwarded to a message router 124 (Page 64, line 9 to Page 66, line 30). The 
message router 124 locates one or more station IDs from at least one of the 
customer ID and device ID previously stored within the message router -124 
(Page 64, line 9 to Page 66, line 30). The message router 124 determines a 
communication type associated with each station ID (Page 64, line 9 to Page 66, 
line 30). The alert is forwarded to a protocol gateway 116 associated with the 
determined communication type (Page 64, line 9 to Page 66, line 30). The 
protocol gateway 116 transmits the alert over a network 1 14 to the client devices 
1 12 (Page 64, line 9 to Page 66, line 30). 

Applicants disclose a method, as recited by claim 37, of sending an 
alert to selected client devices 112 in a communications system comprising 
generation of an alert with a server application, the alert including customer 
information (Page 62, lines 7-20). A station ID of the client device is retrieved 
from the customer information previously stored within a message router 124 
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(Page 63, lines 6-23). A communication type of the client device 1124 is 
determined based on the station ID (Page 63, line 12). One or more of a plurality 
of protocol gateways 116 is selected based on a communication type (Page 63, 
lines 12-14). The alert is forwarded to the selected one or more of the plurality of 
protocol gateways 116 (Page 63, lines 12-14). The alert is formatted with the 
protocol gateway 1 16 for the selected client device 112 (Page 12, line 1 1 to Page 
13, line 6). 

Applicants disclose a system, as recited by claim 49, for sending an 
alert to selected client devices 112 in a communications system 100 including 
means for generating said alert with a server application wherein the alert 
includes customer information (Page 62, lines 7-20; Figures 8A-8C). The system 
including means for retrieving a station ID of the client device 112 is retrieved 
from the customer information previously stored within the message router 124 
(Page 63, lines 6-8). The system including means for determining the 
communication type of the client device 112 based on the station ID (Page 63, 
line 12) and means for selecting one or more of the plurality of protocol gateways 
116 based on the communication type (Page 63, lines 12-14. The system 
including means for forwarding the alert to the selected one or more of the 
plurality of protocol gateways 116 (Page 63, lines 12-14) and means for 
formatting the alert with the protocol gateway 116 for the selected client device 
112 (Page 12, line 11 to Page 13, line 6). 

Applicants disclose a system, as recited by claim 52, for sending 
alerts to client devices 112 comprising means for generating said alert at a 
server, the alert including a customer ID and a device ID (Page 64, lines 15-24). 
The system including means for forwarding the alert to a message router 124 
(Page 64, line 9 to Page 66, line 30) and means for locating with said message 
router 124 one or more station IDs from at least one of the customer ID and 
device ID previously stored within the message router 124 (Page 64, line 9 to 
Page 66, line 30). The system including means for determining with said 
message router 124 a communication type associated with each station ID (Page 
64, line 9 to Page 66, line 30). The system including means for forwarding said 
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alert to a protocol gateway 116 associated with the determined communication 
type (Page 64, line 9 to Page 66, line 30) and a means for transmitting said alert 
with the protocol gateway 116 over a network 1 14 to the client devices 112 (Page 
64, line 9 to Page 66, line 30). 



(6) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

(A) Whether claims 1-6, 9, 12, 13, 23, 24, 29 and 36-53 are anticipated 
under 35 U.S.C. §102(e) by U.S. Patent No. 6,826,173 to Kung ("Kung"). 

(B) Whether claims 14-22 and 30-35 are obvious under 35 U.S.C. 
§1 03(a) over Kung in view of U.S. Patent No. 6,683,870 to Archer 
("Archer"). 

(C) Whether claims 7, 8, 25, 26, 43, 44, 54 and 55 are obvious under 
35 U.S.C. §1 02(e) over Kung in view of U.S. Patent No. 6,138,158 to 
Boyle et al. ("Boyle"). 

(D) Whether claims 10, 11, 27, 28, 46 and 47 are obvious under 35 
U.S.C. §1 02(e) over Kung in view of U.S. Patent No. 6,507,589 to 
Ramasubramani et al. ("Ramasubramani"). 

(7) ARGUMENT 

(A) Claims 1-6. 9. 12, 13. 23. 24. 29 and 36-53 are not 
anticipated under 35 U.S.C. § 102(e) bv Kung. 

All rejected system and method claims 1-6, 9, 12, 13, 23, 24, 29 
and 36-53 require any of customer information, customer ID and device ID t o be 
stored within a message router . 

The Examiner ACKNOWLEDGED in the Office Action dated March 
17, 2006 that Kung allegedly discloses "preference data is the user specified 
information detailing where the user wants the call to do, and the terminal 
configuration data is information about the devices connected to the broadband 
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residential gateway and specify which device can receive which type of call, and 
Column 13, lines 15-24, where the preference data is stored previously on a 
database obtained easy by the router (Call manager)". 

Thus, the Examiner acknowledged that Kung allegedly discloses 
preference data that is previously stored in a call manager is easily obtained by 
a router. The Examiner appears to be equating a Kung's router and Kung's call 
manager. However, Kung's router and call manager are two distinct elements 
within Kung's network, i.e., router is disclosed as item 210 and call manager is 
disclosed as item 218, with nothing within Kung disclosing router 210 has any 
capability to store any type of information. Thus, the Examiner 
ACKNOWLEDGED that Kung discloses preference data stored within a call 
manager NOT stored within a router , much less disclose customer information, 
customer ID and device ID stored within a message router , as recited by claims 
1-6, 9, 12, 13, 23, 24, 29 and 36-53. 

Moreover, Kung at col. 13, lines 15-24 is a small portion of a 
paragraph that begins at col. 13, line 9. Kung's paragraph beginning at col. 13, 
line 9 describes various types of information that are stored in databases within 
call manager 218. Kung at col. 13, lines 15-24 fails to address features 
associated with a router 210. 

The Advisory Action dated June 5, 2006 further compounds 
Applicants' frustration. The Examiner alleged Kung that discloses "the station ID 
and customer configuration information was stored on a router, wherein the 
information is stored in the IP central station (Fig. 1, element 200) where the 
central station includes a call manager (Figure 2, element 218) this call manager 
is part of the central station and contains all the preference information and 
station ID (Column 7, lines 62-67 and Column 13, lines 15-24) as part of the 
router and the information is stored in a database within the router." 

The Advisory Action dated June 5, 2006 alleges that the station ID 
and customer configuration information was stored on a router, wherein the 
information is stored in the IP central station. Nothing within Kung supports 
router 210 performs ANY type of storage . Thus, the Examiner cannot assume 
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Kung's router 210 is performing anything other than conventional routing of data 
packets within a network. 

Moreover, Kung's central station is disclosed as item 200. 
However, also part of the central station 200 is the Internet 180 and a Public 
Switched Telephone Network 160. Thus, central station 200 is NOT a single 
device that includes a router but a plurality of devices that are interconnected. 
As discussed above, Kung's router and call manager are two distinct elements 
within Kung's network, i.e., router is disclosed as item 210 and call manager is 
disclosed as item 218, with nothing within Kung disclosing router 210 has any 
capability to store any type of information. Thus, Kung fails to disclose or 
suggest any of customer information, customer ID and device ID t o be stored 
within a message router , as recited by claims 1-6, 9, 12, 13, 23, 24, 29 and 36- 
53. 

Moreover, all rejected system and method claims 1-6, 9, 12, 13, 23, 
24, 29 and 36-53 require retrieving a station ID of a client device from any of 
customer information, customer ID and device ID previously stored within a 
message router . 

Moreover, even if Kung disclosed preference data stored within a 
router, which the Examiner acknowledged that Kung fails to do in the Office 
Action dated March 17, 2006, a thorough reading of Kung appears to verify the 
Examiner's allegation that Kung's preference data details "where the user wants 
the call to do, and the terminal configuration data is information about the devices 
connected to the broadband residential gateway and specify which device can 
receive which type of call". Thus, Kung fails to disclose retrieving a station ID of 
a client device FROM another type of information , much less retrieving a station 
]D of a client device FROM another type of information previously stored within a 
message router , much less disclose a system and method of retrieving a station 
ID of a client device FROM any of customer information, customer ID and device 
ID previously stored within a message router , as recited by claims 1-6, 9, 12, 
13, 23, 24, 29 and 36-53. 
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A benefit of retrieving a station ID of a client device from any of 
customer information, customer ID and device ID previously stored within a 
message router is, e.g., providing an alert to more stations. In many instances, 
an alert service may want to send an alert to stations without knowing all of the 
station IDs of stations and their associated station IDs attached to a network. 
Conventionally, alerts are only able to be sent to stations with station ID known in 
advance . However, an alert source may want to target additional stations. By 
retrieving a station ID of a client device from any of customer information, 
customer ID and device ID previously stored within a message router , an alert 
can be sent to stations without knowing in advance station IDs. The cited prior 
art fails to disclose or suggest the claimed features having such benefits. 

Hence, the rejection should be withdrawn because it fails to 
demonstrate that the applied reference discloses each and every element of the 
claim , as discussed above. See MPEP 2131. "The identical invention must be 
shown in as complete detail as is contained in the ... claim." Richardson v. Suzuki 
Motor Co. . 868 F.2d 1226, 1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
"Anticipation cannot be predicated on teachings in the reference which are vague 
or based on conjecture." Studiengesellschaft Kohle mbH v. Dart Industries. Inc. . 
549 F. Supp. 716, 216 USPQ 381 (D. Del. 1982), aff'd. . 726 F.2d 724, 220 USPQ 
841 (Fed. Cir. 1984). 

It is respectfully submitted that not only does this rejection fail on its 
face, and thus is improper, but also in light of the above comments its clear that 
Kung does not anticipate any of claims 1-6, 9, 12, 13, 23, 24, 29 and 36-53. 
Thus, the rejection of claims 1-6, 9, 12, 13, 23, 24, 29 and 36-53 under 35 U.S.C. 
§ 102(e) is improper and should be reversed. 

(B) Claims 14-22 and 30-35 are not obvious under 35 U.S.C. 
§1 03(a) over Kung in view of Archer. 

All rejected system and method claims 14-22 and 30-35 require 
retrieving a station ID of a client device from any of customer information, 
customer ID and device ID previously stored within a message router . 

8 
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Archer is relied on to disclose sending a message to a device that 
is considered active and to send a message to all device that a subscriber has in 
his account (See Office Action dated March 17, 2006, page 7). 

Thus, Kung modified by the disclosure of Archer would STILL fail to 
disclose or suggest a system and method of retrieving a station ID of a client 
device from another type of information , much less retrieving a station ID of a 
client device from any of customer information, customer ID and device ID 
previously stored within a message router , as recited by claims 14-22 and 30- 
35. 

Moreover, Claims 14-20 and 31-35 recite a system and method 
relying on a device ID that can be set to all devices. 

The Office Action dated March 17, 2006 acknowledged that Kung 
fails to disclose an alert that includes an active device only flag and a device ID 
set to all devices (See Office Action dated March 17, 2006, page 7). The Office 
Action dated March 17, 2006 relied on Archer to allegedly make up for the 
deficiencies in Kung to arrive at the claimed features. The Applicants respectfully 
disagree. 

The Examiner ACKNOWLEDGED that Archer discloses sending a 
message to all devices that a subscriber has added to his account. Thus, the 
Examiner ACKNOWLEDGED that Archer simply discloses sending a message to 
all devices specified within an account NOT setting any type of device ID to all 
devices, as recited by claims 14-20 and 31-35. 

It is respectfully submitted that not only does this rejection fail on its 
face, and thus is improper, but also in light of the above comments its clear that 
Kung in view of Archer does not render obvious any of claims 14-20 and 31-35. 
Thus, the rejection of claims 14-20 and 31-35 under 35 U.S.C. § 103(a) is 
improper and should be reversed. 
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(C) Claims 7. 8. 25. 26. 43. 44. 54 and 55 are not obvious under 
35 U.S.C. 5103(a) over Kunq in view of Bovle. 

All rejected system and method claims 7, 8, 25, 26, 43, 44, 54 and 
55 require retrieving a station ID of a client device from any of customer 
information, customer ID and device ID previously stored within a message 
router . 

The Examiner relies on Boyle to allegedly make up for the 
deficiencies in Kung to arrive at the claimed features. The Applicants respectfully 
disagree. 

The Office Action dated March 17, 2006 acknowledged that Kung 
fails to disclose segmenting an alert with a selected protocol gateway into 
message segments before sending the alert over a network and having the client 
reconstruct the message segments (See Office Action dated March 17, 2006, 
page 11). The Office Action dated March 17, 2006 relied on Boyle at col. 13, 
lines 37-48 to allegedly make up for the deficiencies in Kung to arrive at the 
claimed features. The Applicants respectfully disagree. 

Boyle discloses at col. 13, lines 37-48 segmenting a PUSH PDU 
into a sequence of fragments, each being treated as a short message with a 
length no more than the maximum length allowed in a SMSC. However, Boyle, 
like Kung, fails to disclose or suggest retrieving of a station ID from another type 
of information , much less disclose or suggest retrieving a station ID from any of 
customer information, customer ID and device ID . much less retrieving a station 
|D of a client device from any of customer information, customer ID and device ID 
previously stored within a message router , as recited by claims 7, 8, 25, 26, 43, 
44, 54 and 55. 

Thus, Kung theoretically modified by the disclosure of Boyle would 
STILL fail to disclose or suggest retrieving a station ID of a client device from any 
of customer information, customer ID and device ID previously stored within a 
message router , as recited by claims 7, 8, 25, 26, 43, 44, 54 and 55. 

It is respectfully submitted that not only does this rejection fail on its 
face, and thus is improper, but also in light of the above comments its clear that 
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Kung in view of Boyle does not render obvious any of claims 7, 8, 25, 26, 43, 44, 
54 and 55. Thus, the rejection of claims 7, 8, 25, 26, 43, 44, 54 and 55 under 35 
U.S.C. § 103(a) is improper and should be reversed. 

(D) Claims 10, 11. 27, 28, 46 and 47 are obvious under 35 
U.S.C. §1 03(a) over Kung in view of Ramasubramani. 

All rejected system and method claims 10, 11, 27, 28, 46 and 47 
require retrieving a station ID of a client device from any of customer information, 
customer ID and device ID previously stored within a message router . 

The Office Action dated March 17, 2006 acknowledged that Kung 
fails to disclose returning an acknowledgement from a client to a protocol 
gateway and then forwarded to a server (See Office Action dated March 17, 
2006, page 11). The Office Action dated March 17, 2006 relied on 
Ramasubramani at col. 8, lines 20-35 to allegedly make up for the deficiencies in 
Kung to arrive at the claimed features. The Applicants respectfully disagree. 

Ramasubramani at col. 8, lines 20-35 discloses an Internet receive 
process and a deliver process, the deliver process waiting for an 
acknowledgement that a notification was received and may also retry the sending 
as needed. However, Ramasubramani, like Kung and Boyle, fails to disclose or 
suggest retrieving of a station ID from another type of information , much less 
disclose or suggest retrieving a station ID of a client device from any of customer 
information, customer ID and device ID previously stored within a message 
router , as recited by claims 10, 1 1 , 27, 28, 46 and 47. 

Thus, Kung modified by the disclosure of Ramasubramani would 
STILL fail to disclose or suggest retrieving a station ID of a client device from any 
of customer information, customer ID and device ID previously stored within a 
message router , as recited by claims 10, 11, 27, 28, 46 and 47. 

It is respectfully submitted that not only does this rejection fail on its 
face, and thus is improper, but also in light of the above comments its clear that 
Kung in view of Ramasubramani does not render obvious any of claims 10, 11, 



n 



BONEFAS et al. - Appln. No. 09/723,285 



27, 28, 46 and 47. Thus, the rejection of claims 10, 11, 27, 28, 46 and 47 under 
35 U.S.C. § 103(a) is improper and should be reversed. 



For all the reasons set forth above, the rejections of claims 1-55 are 



improper and should be reversed. The Applicants therefore respectfully request 
that this Appeal be granted and that the rejections of the claims be reversed. 



MANELLI DENISON & SELTER PLLC 

2000 M Street, N.W. 7th Floor 

Washington D.C. 20036-3307 

Tel. (202) 261-1020 

Fax. (202) 887-0336 

WHB/df 



CONCLUSION 



Respectfully submitted 




William H. Bollman 
Reg. No.: 36,457 
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APPENDIX 
CLAIMS INVOLVED IN THE APPEAL 

1. A method of sending an alert to selected client devices in a 
communications system including a server adapted to run a server application, a 
message router communicating with the server, a plurality of protocol gateways 
communicating with the message routers, and a network adapted to couple the 
server and the protocol gateways to client devices, comprising: 

generating said alert with said server application, said alert 
including customer information; 

sending said alert to said message router; 

retrieving a station ID of said client device from said customer 
information previously stored within said message router; 

determining a communication type of said client device based on 
said station ID; 

selecting one or more of said plurality of protocol gateways based 
on said communication type; and 

forwarding said alert to said selected one or more of said plurality of 
protocol gateways; 

formatting said alert with said protocol gateway for said selected 
client device; and 

forwarding said formatted alert via said network to said selected 

client device. 

2. The method of claim 1 , wherein: 

said customer information includes at least one of a customer ID 
and a port number. 

3. The method of claim 2 A wherein: 

said step of determining a communication type further comprises 
searching a user table to obtain said station ID associated with said customer ID. 
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4. The method of claim 2, wherein: 

said step of determining a communication type further comprises 
searching a local cache of said message router for said station ID associated 
with said customer ID. 

5. The method of claim 2, wherein: 

said step of determining a communication type further comprises 
searching a local cache of said message router and a device table for a first 
device associated with said customer ID when both said customer ID and port 
number are provided. 

6. The method of claim 1 , further comprising: 

returning an inactive customer message to said server if no station 
ID is retrieved. 

7. The method of claim 1 , further comprising: 

segmenting said alert with said selected protocol gateway into 
message segments before sending said alert over said network. 

8. The method of claim 7, further comprising: 
assembling said message segments at said client device. 

9. The method of claim 1 , wherein: 

said alert includes at least one of an alert message, a compression 
flag, an encryption flag, and an acknowledgement flag. 

1 0. The method of claim 1 , further comprising: 

returning an acknowledgement to said selected protocol gateway 
after receiving said formatted alert message at said client device. 
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1 1 . The method of claim 1 0, further comprising: 

forwarding said acknowledgement from said selected protocol 
gateway to said server. 

12. The method of claim 1 , wherein: 

said customer information is a client information object. 

1 3. The method of claim 12, wherein: 

said client information object includes a customer ID and a device 

ID. 

14. The method of claim 13, wherein: 

said alert includes an active device only flag and wherein said 
device ID can be set to all devices. 

15. The method of claim 14, further comprising: 

searching a local cache of said message router for said station ID if 
said active device only flag is set and said device ID is specified. 

16. The method of claim 15, further comprising: 

searching a user table for said station ID if said station ID is not 
located in said local cache. 

17. The method of claim 14, further comprising: 

searching only said user table for active client devices associated 
with said customer ID if said active device only flag is set and said device ID is 
set to all devices. 
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18. The method of claim 14, further comprising: 

searching a local cache of said message router for said station ID if 
said active device only flag is not set and said device ID is specified. 

19. The method of claim 18, further comprising: 

searching a device table for said station ID if said station ID is not 
located in said local cache. 

20. The method of claim 14, further comprising: 

searching a device table for client devices associated with said 
customer ID if said active only flag is not set and said device ID is set to all 
devices. 

21 . The method of claim 1 , further comprising: 

providing each station ID retrieved in said step of retrieving a 
station ID to said server. 

22. The method of claim 1 , further comprising: 

providing each station ID retrieved by said message router to said 
server, before forwarding said alert to said protocol gateway. 
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23. A method of sending alerts to client devices, comprising: 
generating said alert at a server, said alert including a customer ID 

and a device ID; 

forwarding said alert to a message router; 

locating with said message router one or more station IDs from at 
least one of said customer ID and device ID previously stored within said 
message router; 

determining with said message router a communication type 
associated with each station ID; 

forwarding said alert to a protocol gateway associated with said 
determined communication type; and 

transmitting said alert with said protocol gateway over a network to 
said client devices. 

24. The method of claim 23, further comprising: 

receiving said alert with a transport layer of an application running 
on said protocol gateway and sending said alert from said transport layer to client 
applications. 

25. The method of claim 24, further comprising: 

segmenting said alert into message segments with said protocol 

gateway. 

26. The method of claim 25, wherein: 

said client application assembles said message segments. 

27. The method of claim 23, further comprising: 

sending an acknowledgement from said client device to said 
protocol gateway once said alert is received by said client device. 
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28. The method of claim 27, further comprising: 
sending said acknowledgement from said protocol gateway to said 

server that forwarded said alert after receiving said acknowledgement from said 

client device. 



29. The method of claim 23, wherein: 

said alert comprises at least one of an alert message, a client 
information object including said customer ID and device ID, message flags, 
compression flag and an encryption flag. 

30. The method of claim 29, wherein said messages flags 
specify at least one of: 

whether said server requires an acknowledgement message; 

whether said alert should be sent only if said client device is 
currently active; and 

whether said protocol gateway should only attempt message 
delivery once. 



31 . The method of claim 23, wherein: 

said alert includes an active device only flag and said device ID can 
be set to all devices. 
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32. The method of claim 31, wherein said locating step 

comprises: 

searching a local cache of said message router for said station ID if 
said active device only flag is set and said device ID is specified; 

searching only a user table for active client devices associated with 
said customer ID if said active device flag is set and said device ID is set to all 
devices; 

searching a local cache of said message router for said station ID if 
said active device only flag is not set and said device ID is specified; and 

searching a device table for client devices associated with said 
customer ID if said active device only flag is not set and said device ID is set to 
all devices. 

33. The method of claim 32, further comprising: 
for said steps of searching a local cache of said message router, 

a database for said station ID if said station ID is not found in said local 

34. The method of claim 31 , further comprising: 
providing each device ID located to server if device ID is set to all 

devices. 

35. The method of claim 31 , further comprising: 

sending an inactive message to said server if no device is located 
and said device ID is set to all devices, otherwise sending a customer not valid 
message. 

36. The method of claim 23, further comprising: 

formatting said alert for said client device with said protocol 

gateway. 



searching 
cache. 
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37. A method of sending an alert to selected client devices in a 
communications system, comprising: 

generating said alert with a server application, said alert including 
customer information; 

retrieving a station ID of said client device from said customer 
information previously stored within a message router; 

determining a communication type of said client device based on 
said station ID; 

selecting one or more of a plurality of protocol gateways based on a 
communication type; and 

forwarding said alert to said selected one or more of said plurality of 
protocol gateways; and 

formatting said alert with said protocol gateway for said selected 

client device. 

38. The method of claim 37, wherein: 

said customer information includes at least one of a customer ID 
and a port number. 

39. The method of claim 38, wherein: 

said step of determining a communication type further comprises 
searching a user table to obtain said station ID associated with said customer ID. 

40. The method of claim 38, wherein: 

said step of determining a communication type further comprises 
searching a local cache of a message router for said station ID associated with 
said customer ID. 
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41 . The method of claim 36, wherein: 

said step of determining a communication type further comprises 
searching a local cache of a message router and a device table for a first device 
associated with said customer ID when both said customer ID and port number 
are provided. 

42. The method of claim 37, further comprising: 

returning an inactive customer message to said server if no station 
ID is retrieved. 

43. The method of claim 37, further comprising: 

segmenting said alert with said selected protocol gateway into 
message segments before sending said alert over said communications system. 

44. The method of claim 43, further comprising: 
assembling said message segments at said client device. 

45. The method of claim 37, wherein: 

said alert includes at least one of an alert message, a compression 
flag, an encryption flag, and an acknowledgement flag. 

46. The method of claim 37, further comprising: 

returning an acknowledgement to said selected protocol gateway 
after receiving said formatted alert message at said client device. 

47. The method of claim 46, further comprising: 

forwarding said acknowledgement from said selected protocol 
gateway to said server. 
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48. The method of claim 37, wherein: 

said customer information is a client information object. 



49. A system for sending an alert to selected client devices in a 
communications system, comprising: 

means for generating said alert with a server application, said alert 
including customer information; 

means for retrieving a station ID of said client device from said 
customer information previously stored within a message router; 

means for determining a communication type of said client device 
based on said station ID; 

means for selecting one or more of a plurality of protocol gateways 
based on a communication type; and 

means for forwarding said alert to said selected one or more of said 
plurality of protocol gateways; and 

means for formatting said alert with said protocol gateway for said 
selected client device. 

50. The system for sending an alert to selected client devices in 
a communications system according to claim 49, wherein: 

said customer information includes at least one of a customer ID 
and a port number. 

51. The system for sending an alert to selected client devices in 
a communications system according to claim 50, wherein: 

said means for determining a communication type comprises a 
means for searching a user table to obtain said station ID associated with said 
customer ID. 
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52. A system for sending alerts to client devices, comprising: 

means for generating said alert at a server, said alert including a 
customer ID and a device ID; 

means for forwarding said alert to a message router; 

means for locating with said message router one or more station 
IDs from at least on of said customer ID and device ID previously stored within 
said message router; 

means for determining with said message router a communication 
type associated with each station ID; 

means for forwarding said alert to a protocol gateway associated 
with said determined communication type; and 

means for transmitting said alert with said protocol gateway over a 
network to said client devices. 



53. The system for sending alerts to client devices according to 
claim 52, further comprising: 

means for receiving said alert with a transport layer of an 
application running on said protocol gateway and sending said alert from said 
transport layer to client applications. 

54. The system for sending alerts to client devices according to 
claim 53, further comprising: 

means for segmenting said alert into message segments with said 
protocol gateway. 



55. The method of claim 54, wherein: 

said client application assembles said message segments. 
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EVIDENCE APPENDIX 



None 
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RELATED PROCEEDINGS APPENDIX 

None 
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